IBIS Macromodel Task Group Meeting date: 05 Feb 2013 Members (asterisk for those attending): Agilent: Fangyi Rao * Radek Biernacki Altera: * David Banas Julia Liu Hazlina Ramly Andrew Joy Consulting: Andy Joy ANSYS: Samuel Mertens * Dan Dvorscak * Curtis Clark Steve Pytel * Luis Armenta Arrow Electronics: Ian Dodd Cadence Design Systems: Terry Jernberg * Ambrish Varma Feras Al-Hawari Brad Brim Kumar Keshavan Ken Willis Cavium Networks: Johann Nittmann Celsionix: Kellee Crisafulli Cisco Systems: Ashwin Vasudevan Syed Huq Ericsson: * Anders Ekholm IBM: Greg Edlund Intel: * Michael Mirmak Maxim Integrated Products: Mahbubul Bari Hassan Rafat Ron Olisar Mentor Graphics: * John Angulo Zhen Mu * Arpad Muranyi Vladimir Dmitriev-Zdorov Micron Technology: Randy Wolff Justin Butterfield NetLogic Microsystems: Ryan Couts Nokia-Siemens Networks: Eckhard Lenski QLogic Corp. James Zhou SiSoft: * Walter Katz Todd Westerhoff Doug Burns * Mike LaBonte Snowbush IP: Marcus Van Ierssel ST Micro: Syed Sadeghi Teraspeed Consulting Group: Scott McMorrow * Bob Ross TI: Casey Morrison Alfred Chong Vitesse Semiconductor: Eric Sweetman Xilinx: Mustansir Fanaswalla Ray Anderson The meeting was led by Arpad Muranyi ------------------------------------------------------------------------ Opens: - Arpad: We need to introduce Walter's recent BIRD - Walter: It would be useful to review Arpad's excellent DesignCon presentation -------------------------- Call for patent disclosure: - None ------------- Review of ARs: - None ------------- New Discussion: Interconnect Task Group report: - Michael M: On Jan 23 we discussed summit material and David Banas' survey Analog modeling plan: - Arpad: After the end of the summit we discussed the SiSoft/Agilent press release - The authors were given an unofficial AR to propose the method they are using - Hopefully this will be discussed soon - Walter: I have vacation, it will be ready in 2 weeks - Arpad: It seems the idea of two parallel approaches is bottoming out - The BIRDs I like would allow IBIS modeling as well as AMI - The approaches have some overlap - Walter: IBIS-ISS would allow legacy IBIS broadband models - The idea here is to represent on-die interconnect as broadband - Non-AMI solutions would best target non-LTI using legacy buffers - Arpad: We could review the BIRDs involved - The Cadence BIRD 145 also allows broadband models - A slide set should be made - We should set aside time for long term overhaul of keywords like [Model] Arpad show the presentation "What's Wrong with IBIS?": - slide 2: - Arpad: We must decide whether to tweak or leave behind. - The legacy syntax is unappealing - This might involve many IBIS feature changes - Walter: EMD is not a leave behind approach - It addresses all industry interconnect needs - IBIS has various interconnect solutions, which would not be touched - The final problem is on-die interconnect, which EMD can address - Modifications for pre and post layout might be needed - The existing models can be unaffected - Only minor tweaks to IBIS are needed - slide 3: - Arpad: We both have content related issues, but also usage issues - Stacked die support is a problem, we have no [Die] keyword - IBIS [Pin] is targeted for post-layout - Walter: Disagree, a stacked die should go in EMD, not IBIS - Arpad: I had some syntax examples, but it was too long for the summit - We should have a planned effort to clean up the IBIS specification - Radek: That would be good, a review of the IBIS specification structure - Bob: This sets a new direction, seeming to abandon [External Model] and [External Circuit] - Arpad: Yes, I am thinking about a new model keyword, object oriented - It should not be layered the way we have it now, where one language calls another - Radek: Those do not seem to be popular - Michael M: There may be interest in tying IBIS to HDL languages - Arpad: IBIS-ISS is universally accepted, but BIRD 116 is not well received - A new keyword may solve that - Walter: ISS is for interconnect, [External Model] is not - An IBIS-BSS might work - Arpad: We chose an LTI subset of HSPICE, but not excluding other possibilities - Walter: IBIS-ISS was created after we decided EMD needed it - Bob: We could use any SPICE brand as a superset - The idea was to connect any kind of buffer to pins - As it stands EDA vendors are getting around the problem with proprietary solutions - Arpad: We must decide if a new meeting is needed for an overhaul, or use this one - We still have BIRDs to work on - Michael M: The people will be the same anyway - A combined meeting would be best, this one - Arpad: The Advanced Technology meeting would be best for futures work David: Can we agree to decide on BIRDs 116 and 122 in two weeks? - Arpad: Yes, and next week we can discuss redrivers - Radek: Fangyi may not be here next week - Walter: A repeater can a redriver or a retimer - Fangyi's flows are nearly identical for a retimer - Arpad: Can Walter speak for BIRD 131? - Ambrish: There is nothing in the AMI file for what happens between RX and TX - Walter: SiSoft believe both Init and GetWave flows should be supported - Some support this and others produce separate models - With a repeater there can be more flows to support, without rules requiring specific support - Ambrish: I would like to see a case that is a problem - Radek: Fangyi would rather not combine BIRDs 131 and 156 - Arpad: Fangyi's BIRD is only for redrivers - Michael M: BIRD 156 needs to be relabeled - There has to be a flow to describe how data gets from the RX to TX side - Only BIRD 131 has the keyword to say the RX and TX are connected - Ambrish: Fangyi believes [Repeater Pin] changes traditional IBIS waveforms - Michael M: We could say repeater has to have an AMI model - Otherwise we would have to be clever - This is just like [Series Switch], it might be put in there - Bob: It might be [AMI Repeater] - Michael M: Only if [Series Switch] is not adequate - Walter: Retimers want to use multiple ways to generate the TX side impulse response - Redrivers have no digital stimulus, how to generate the impulse response? - Arpad: Do we need two BIRDs? - Walter: The repeater BIRD should stay the same - I could create a new BIRD for retimers - Ambrish: I would prefer to add to BIRD 156 instead of having 3 BIRDs - Walter: I will add it only if Fangyi and I can't agree Arpad: If Fangyi is not here next week can we discuss backchannel? - Ambrish: Not sure we will be ready to discuss BIRD 147 - Radek: We could discuss BIRD 155 - Arpad: We will plan to discuss BIRD 155 AR: Ambrish email reflector regarding BIRD 147 status ------------- Next meeting: 12 Feb 2013 12:00pm PT Next agenda: 1) Task list item discussions ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives